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Abstract 
This memo updates the registry of properties in Authentication- 
Results: message header fields to allow relaying of the results of a 
Vouch By Reference query. 
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1. Introduction 


[AUTHRES] defined a new header field for electronic mail messages 
that presents the results of a message authentication effort in a 
machine-readable format. In the interim, a proposal for rudimentary 
domain-level reputation assessment, called Vouch By Reference, [VBR] 
was published and is now beginning to see popular use. 


This memo thus registers an additional reporting property allowing a 
VBR result to be relayed as an annotation in a message header. 


2. Keywords 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [KEYWORDS]. 


3. Discussion 


Vouch By Reference [VBR] introduced a mechanism by which a message 
receiver can query a "vouching" service to determine whether or not a 
trusted third party is willing to state that mail from a particular 
source can be considered legitimate. When this assessment is done at 
an inbound border mail gateway, it would be useful to relay the 
result of that assessment to internal mail entities such as filters 
or user agents. 


Reactions to the information contained in an Authentication-Results 
header field that contains VBR (or any) results are not specified 
here, as they are entirely a matter of local policy at the receiver. 
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4. 


Definition 


This memo adds to the "Email Authentication Methods" registry, 
created by IANA upon publication of [AUTHRES], the following: 


o The method "vbr"; and 


o Associated with that method, the properties (reporting items) 
"header.md" and "header.mv". 


If "header.md" is present, its value MUST be the DNS domain name 
about which a VBR query was made. If "header.mv" is present, its 
value MUST be the DNS domain name that was queried as the potential 
voucher for the "header.md" domain. 


If the VBR query was made based on the content of a "VBR-Info" header 
field present on an incoming message, "header.md" is typically taken 
from the "md" tag of the "VBR-Info" header field, and "header.mv" is 
typically one of the values of the "mv" tag in the "VBR-Info" header 
field on that message. However, [VBR] permits a different mechanism 
for selection of the subject domain and/or list of vouchers, ignoring 
those present in any "VBR-Info" header field the message might have 
included. A server could even conduct a VBR query when no "VBR-Info" 
field was present, based on locally configured policy options. Where 
such mechanisms are applied, the verifying server MAY generate an 
Authentication-Results field to relay the results of the VBR query. 


This memo also adds to the "Email Authentication Result Names" 
registry the following result codes and definitions: 


none: No valid VBR-Info header was found in the message, or a domain 
name to be queried could not be determined. 


pass: A VBR query was completed, and the vouching service queried 
gave a positive response. 


fail: A VBR query was completed, and the vouching service queried 
did not give a positive response, or the message contained 
multiple VBR-Info header fields with different "mc" values 
(see [VBR]). 


temperror: A VBR query was attempted but could not be completed due 
to some error that is likely transient in nature, such as a 
temporary DNS error. A later attempt may produce a final result. 
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permerror: A VBR query was attempted but could not be completed due 
to some error that is likely not transient in nature, such as a 
permanent DNS error. A later attempt is unlikely to produce a 
final result. 


5. IANA Considerations 


Per [IANA], the following items have been added to the "Email 
Authentication Methods" registry: 


t------------ bonnes a Sees +-------- N A eT + 
| Method | Defined | ptype | property | value 
t------------ A S T E 4$----------------- + 
| vbr | RFC 6212 | header | md | DNS domain name | 
| | | | | used as the | 
subject of a 
VBR query 
4+------------ +---------- +-------- t---------------- 4+----------------- + 
| vbr | RFC 6212 | header | mv | DNS domain name | 
| | | | | of the entity 
| | | | | acting as | 
| | | | | the voucher | 
Farti proset pan patena peA + 
Also, the following items have been added to the "Email 
Authentication Result Names" registry: 
+----------- E Sa ecto +--------- torrean An + 
| Code | Existing/New | Defined In | Method | Meaning 
4+----------- +-------------- +------------ +--------- +----------------- + 
| none | existing | RFC 5451 | vbr | Section 4 of | 
| | | | (added) | RFC 6212 | 
4+----------- 4+-------------- +------------— 4+--------- 4+----------------- + 
pass existing RFC 5451 vbr Section 4 of 
(added) RFC 6212 
peso ce See ee hes et a iter eee tas +--------- oS eee See + 
| fail | existing | RFC 5451 | vbr | Section 4 of | 
| | | | (added) | RFC 6212 | 
+----------- 4t-------------- | aR RS echoes 4+--------- t----------------- + 
temperror existing RFC 5451 vbr Section 4 of 
(added) RFC 6212 
4+----------- +-------------- 4+------------ 4+--------- +----------------- + 
| permerror | existing | RFC 5451 | vbr | Section 4 of | 
| | | | (added) | RFC 6212 | 
+----------- +-------------- +------------— 4+--------- +----------------- + 
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6. Security Considerations 


This memo creates a mechanism for relaying [VBR] results using the 
structure already defined by [AUTHRES]. The Security Considerations 
sections of those documents should be consulted. 
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Appendix A. Authentication-Results Examples 


This section presents an example of the use of this new header field 
to indicate VBR results. 


A.1. VBR Results 
A message that triggered a VBR query, returning a result: 


Authentication-Results: mail-router.example.net; 
dkim=pass (good signature) header.d=newyork.example.com 
header .b=oINEO8hg; 
vbr=pass (voucher.example.net) 
header.md=newyork.example.com 
header.mv=voucher.example.org 
Received: from newyork.example.com 
(newyork.example.com [192.0.2.250]) 
by mail-router.example.net (8.11.6/8.11.6) 
for <recipient@example.net> 
with ESMTP id i7PK0sH7021929; 
Fri, Feb 15 2002 17:19:22 -0800 
DKIM-Signature: v=1; a=rsa-sha256; s=rashani; 
d=newyork.example.com; 
t=1188964191; c=relaxed/simple; 
h=From:Date:To:VBR-Info:Message-Id: Subject; 
bh=sEu28nfs9fuZGD/pSr7ANysbY3 jtdaQ3Xv9xPQtSOm7=; 
b=oINEO8hgn/gnunsg ... 9n9ODSNFSDi4j3= 
From: sender@newyork.example.com 
Date: Fri, Feb 15 2002 16:54:30 -0800 
To: meetings@example.net 
VBR-Info: md=newyork.example.com; mc=list; 
mv=voucher.example.org 
Message-Id: <12345.abc@newyork.example.com> 
Subject: here’s a sample 


Example 1: Header Field Reporting Results from a VBR Query 


Here we see an example of a message that was signed using DomainKkKeys 
Identified Mail (DKIM) and that also included a VBR-Info header 
field. On receipt, it is found that the "md=" field in the latter 
and the "d=" field in the former matched, and also that the DKIM 
signature verified, so a VBR query was performed. The vouching 
service, voucher.example.org, indicated that the sender can be 
trusted, so a "pass" result is included in the Authentication-Results 
field affixed prior to delivery. 
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